One method of delivering web content to a web browser client application includes servicing URL requests issued by the web browser client application. Request specifications include the formatting of what are known in the art as Universal Resource Locator (URL) strings. A portion of a typical URL string represents a network address of the web server to which a corresponding URL request is directed.
For example, a web server may provide a keyword-based web-page search service. A web browser client sends a search request for web pages related to “blue skies” to the web server. An exemplary URL request string specification may have the following form:
URL=“http://www.searchservice.org/findwebpages?+blue+sky”
where the “www.searchservice.org” portion represents the network address of the web server provisioning the keyword-based web-page search service, and the remaining portion of the URL string represents the search request.
Legacy web servers providing search services, having received the URL request, provide the search request portion of the URL string to web-page search software applications which parse the search request and respond appropriately. The performance characteristics of such a prior art implementation are closely related to the performance of such web-page search software application. In support of complex solution offerings, software application code provisioning services is modularized perhaps using JAVA™ applet technology to enhance performance in servicing a large number of requests.
Other exemplary prior art solutions include application servers running web-page search software applications. The performance characteristics of such an implementation therefore is closely related to the performance of the application server(s) used as well related to the performance of web-page search software applications executing thereon.
A prior art improvement to servicing the exemplary search request mentioned above is shown in FIG. 1. An application server 100 services the search request using JAVA™ servlets 122, 124, and 126 in response to the “findwebpages” directive. JAVA™ servlets 122, 124, and 126 are provisioned on Dynamo™ software by ATG, a commercially available application server product.
In accordance with the operation of the Dynamo™ software, the URL request 102 is received 132 by a request adapter 104. The request adapter 104 performs front-end processing on the received URL request 102. The request adapter 104 parses 134 the URL request 102 and generates 136 a request object 106 containing URL information for the search request 102 as well as host information corresponding to the communications network node associated with the web-browser client. A response object 108 is also generated.
The request 106 and response 108 objects are processed by the group of Java™ servlets 122, 124, and 126 sequentially. The sequential group of servlets 122, 124, and 126 is known in the art as a request processing pipeline 120. Depending on information contained at least in the request object 106, one or more of the servlets 122, 124, and 126 will perform an operation to service the exemplary search request and update at least the response object 108 before passing the request 106 and response 108 objects to the next servlet in the pipeline 120.
In accordance with the prior art exemplary implementation, the servlet 122 is a web-page search servlet which: extracts 142 the first search term “blue” from the request object 106, generates 144 web-page hits for the first search term, and updates 146 at least the response object 108. The (modified) request 106 and response 108 objects are passed along the servlet pipeline 120.
The servlet 124 is also a web-page search servlet which: extracts 152 the second search term “sky” from the (modified) request object 106, generates 154 web-page hits for the second search term, and updates 156 at least the response object 108. The (modified) request 106 and response 108 objects are passed along the servlet pipeline 120.
The servlet 126 is a list manipulation servlet which: extracts 162 the web-page hits from the modified response object 108, combines 164 the page hits and updates 166 at least the response object 108. The exemplary list manipulation extracts common web-page hits found by both of the servlets 122 and 124. The (modified) request 106 and response 108 objects are passed along and out of the servlet pipeline 120.
A response adapter 110 performing back-end processing of URL requests may be used to: extract 172 the combined hits from the modified response object 108 and generate a web page of hits 174. In generating 136 the response object 108, an HyperText Markup Language (HTML) template to be returned to the web-browser client may be included therein, in which case steps 172 and 174 merely process the HTML template into a web-page 112. Using host information specified in the request object 106, the information held in the serviced response object 108 is sent 176 to the web-browser client as an HTML page 112, in reply to the URL request 102.
Several problems are encountered in using the prior art solution. The request 106 and response 108 objects are passed through each and every servlet 122, 124, and 126 in the pipeline 120 regardless of whether or not a specific servlet (122, 124, and 126) is relevant to the processing of the URL request 102. Much processing time is wasted, if the request 106 and response 108 objects are passed through many servlets irrelevant to processing the corresponding URL request 102, contributing to an inefficient service offering. For example, if only one search term is specified in the search request, the servlet 122 is the only relevant servlet to that particular search request. Passing the request 106 and response 108 objects through the servlets 124 and 126 wastes time, uses request processing resources unnecessarily and is therefore inefficient.
Therefore services provisioned using servlet pipelines, typically utilize a limited number of servlets to balance processing time and resource utilization against the capabilities of the provisioned service. When applied to the exemplary prior art implementation, a limitation on the number of search terms, limiting the capabilities of the search service, therefore becomes necessary to provide reasonable search request processing response times for typical search requests.
Therefore the sequential passing of the request 106 and response 108 objects through the entire pipeline 120 regardless of whether each servlet in the pipeline 120 is relevant to the processing of the URL request 102 leads to unscalability in provisioning services using such an implementation.
Additionally, servlets 124 and 126 must be coded to recognize triggering conditions to cause them to perform their function. Including servlet triggering functionality into servlet code duplicates application code and introduces the risk of optional servlets 124 acting at an inappropriate time or in an inappropriate manner. Furthermore, servlet triggering greatly complicates specialized processing of a URL requests 102.
Other problems relate to modifying a servlet and/or adding a new servlet to a pipeline. Such changes to the pipeline introduces the risk of making the entire pipeline inoperable, since all of the request 106 and response 108 objects flow sequentially through all the servlets in the pipeline.
Yet another problem with using pipelined processing of URL requests comes from the fact that such URL request processing has an all-or-nothing result which greatly complicates the development and debugging of services provisioned using long sequences of servlets.
With the growing demand for web-based services, the ability to control the presentation of web-content to customers is critically important to efficient and effective service provisioning. There therefore is a need to solve the above mentioned problems to improve URL request processing.